V. Remarks 

A. Remarks regarding the Preliminary Amendment 

Consideration and allowance of the subject 
application are respectfully requested. 

Claims 1-46 are pending in the application. Claims 
1, 7, 17, 21, 26, 28, 30, 32, 35, 37 and 40 are independent 
claims . 

New Claims have been added. Additionally, claims 
have been amended to correct a minor typographical errors 
without reducing their scope. 

The specification has been amended to state that 
this application is a continuation of U.S. Patent Application 
No. 09/140,759 in accordance with 37 CFR § 1.78(a) (2) (ii) (B) . 
Additionally, the specification has been amended to include 
matter originally incorporated by reference. No new matter 
has been added. 

The drawings have been amended to add Figure 6 to 
the drawings. 

B. Remarks regarding the Response to the Restriction 
Requirement 

Applicants respectfully request the Restriction 

Requirement mailed by the Office on June 30, 2003, be 

restated because Claims 37, 38 and 39 were not treated 

therein. Additionally, it is requested that claims 40-46 be 
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included in the restated Restriction Requirement. Applicants 
believe that there would be Groups I, II, III and IV in the 
restated Restriction Requirement and that they would be 
stated as follow: 

I. Claims 1-16, 26-27 and 35-39, drawn to a method 
in which a data link between a wired and wireless 
communication system is selected for transmission, classified 
in class 370, subclass 235/238. 

II. Claims 17-25, 28-29 and 32-34, drawn to a 
system and method for carrying out regional communications 
between a plurality of mobile vehicles located within a 
region, classified in class 370, subclass 328. 

III. Claims 3 0-31, drawn to a vehicular system 
that communicates its operational abilities to neighboring 
vehicles, classified in class 370, subclass 252. 

IV. Claims 4 0-46, drawn to a mobile automotive 
telemetry system for installation on board a vehicle, 
classified in class 701, subclass 29; 
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Applicants' undersigned attorney may be reached in 



our Washington, D.C. office by telephone at (202) 625-3500. 
All correspondence should be directed to our address given 



Patent Administrator 
KATTEN MUCHIN ZAVIS ROSENMAN 
525 West Monroe Street 
Suite 1600 

Chicago, Illinois 60661-3693 
Facsimile: (312) 902-1061 



below. 



Respectfully submitted, 




Registration No. 
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I^e Specification- Marked-up version 



REFERENCE TO CO-PENDING APPLICATIONS 



""-" This application is a Continuation of U.S. Patent Application No. 09/140,759 (now U.S. 
Patent No. 6.263.268). filed August 26. 1998 entitled SYSTEM AND METHOD FOR 
PROVIDING MOBILE AUTOMOTIVE TELEMETRY which claims the benefit of U.S. 
Patent Application No. 60/056.388. filed August 26. 1997 entitled SYSTEM AND METHOD 
FOR PROVIDING MOBILE AUTOMOTIVE TELEMETRY. The subject matter of both 
provisional application serial number 60/056,388, filed August 26, 1997, and utility patent 
application serial number 09/140,759, filed August 26, 1998 (both entitled SYSTEM AND 
METHOD FOR PROVIDING MOBILE AUTOMOTIVE TELEMETRY) is incorporated 
herein by reference. The subject matter of PCT Application serial number PCT/CA98/00986, 
filed October 23, 1998 and entitled TELECOMMUNICATIONS SYSTEM and designating the 
United States is also incorporated herein by reference. The subject matter of U.S. provisional 
Application serial number 60/148,270, filed on August 11, 1999 and entitled VEHICULAR 
COMPUTING DEVICE is also incorporated herein by reference. The subject matter of U.S. 
provisional Application serial number 60/187,022, filed on March 6, 2000 is also incorporated 
herein by reference. Applicants claim benefit of each of the above-referenced utility, 
provisional, and PCT applications under 35 U.S.C. §§ 119 and 120. 



The present invention relates to data communications systems and more particularly to 
the field of vehicular telemetry using RF packet networks in conjunction with Internet or similar 
protocols. 

DESCRIPTION OF THE RELATED ART 

Hereinafter numerical reference is made to materials listed in Appendix A at the end of 
the disclosure. 



BACKGROUND OF THE INVENTION 



RECEIVED 



JUL 3 1 2003 



FIELD OF THE INVENTION 



GROUP 3600 
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Conventionally, vehicles have been known to exchange data with a diagnostic computer 
system (such as in a repair garage) over a hardwired or infrared data link, or a regulatory 
computer system (such as a toll highway) by a data link using a low power transponder. 

More sophisticated vehicular telemetry for commercial fleets has been made possible in 
the last several years through satellite RF packet networks. In these vehicular telemetry 
systems, vehicle sensor data can be transported over wireless data links to a computer that's 
programmed to monitor and record automotive phenomena and to support database systems for 
vehicular maintenance, without the need for the vehicle to be in a particular service bay for 
example. However, these systems are relatively expensive to operate. 

A considerable amount of research is being dedicated to developing feasible Intelligent 
Vehicle Highway Systems (rVHS) which -are computer-assisted methods to manage highway 
infrastructures, synchronize traffic lights, measure traffic flow, to alert drivers to ongoing 
traffic conditions through electronic billboards and other innovations aimed at improving the 
quality and efficiency of road transportation systems for vehicles. 

The California Air Resources Board (CARB) has been a leader in establishing 
standards for monitoring vehicle emissions. A recent CARB proposal, known as OBD-III, is 
the third generation of on-board diagnostic requirement, calling for an emissions regulatory 
agency to retrieve, remotely, diagnostic data from vehicles, thereby avoiding the heed of a 
visit to a clean air inspection station. The proposal suggests an ultra low-power transponder 
on each vehicle which is capable of transferring data between the vehicle and a roadside 
receiver. Of course, in order for the OBD-III proposal to proceed, each vehicle must have a 
system capable of collecting and dispatching the requested data through the transponder. 
CARB is actively reviewing currently available technologies and is working with the 
telecommunications industry to see what future equipment is planned. The operating 
platforms tested thus far by CARB have been relatively cumbersome and have limited 
capability to be used for other data exchange needs in the future. There is interest in finding 
a platform that will be economical to operate in order to minimize the financial burden 
placed on the consumer to implement the proposal. 
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Moreover, it would be desirable for the chosen platform to be capable of doing more 
than just sending diagnostic information to a clean air agency. The industry is looking at 
ways to utilize the tremendous business opportunities ofreaehing urban commuters in their 
vehicles while they devote several hours each day to their commute. 

Vehicular traffic has become a major problem for urban planners. With land values 
skyrocketing and land-use issues becoming more of a cone, planners are looking for ways of 
getting more vehicles through existing commuter arteries as an alternative to expanding 
them. It is also known that the actual volume of traffic handled by a thoroughfare plummets 
when trade becomes congested. Therefore, it would be desirable to have vehicles which are 
capable of exchanging data with themselves as a way to control such things as safe driving 
distances to avoid collisions and exchanging data with traffic monitoring systems to control 
such things as driving speeds. 

It is therefore an object of the present invention to provide a improved platform for 
vehicular telemetry. 

It is a further object of the present invention to provide an improved vehicular 
telemetry system which is relatively inexpensive, yet capable of exchanging a range of useful 
data with a dat a communications system. 

It is still a further object of the present invention to provide a vehicle communications 
system in which the vehicles therein are each capable of communicating both with a data 
communications system and with themselves. 

SUMMARY OF THE INVENTION 

Briefly stated, the invention involves a method of exchanging data between a wired 
network and a wireless network, comprising the steps of 

a) providing at least two data links between the networks; 

b) measuring impedance on each data link; and 
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c) transmitting the data across the data link having the lowest impedance. 
Preferably, the method further comprises the step of. 

d) Providing each of the networks with an IEEE 802.1 1 node, wherein one of the 
data links is established therebetween. 

Preferably, the data links are wireless and a first of the data links is established on a Spread 
Spectrum-radio frequency (RF) band. The data links may also comprise a satellite RF packet 
network or a terrestrial RF packet network. It is contemplated that other data links may become 
available in future as wireless data communications evolve. 

In another of its aspects, the present invention provides a communications system, 
comprising 

a mobile communications network havi ng a mobile node, 
a fixed communications network having an access point, 

a pair of alternative data links, each of which joins the mobile node with the access 
point, and 

a switching unit for switching between the alternative data links to exchange data 
between the mobile node and the access point. 

In one embodiment, the mobile communications network includes a plurality of vehicle- 
mounted mobile nodes wherein each is Internet addressable, for example under IM protocol. 
Each mobile node and selected ones of the access points operate under the IF-EE 802. 1 1 
standard. In this case, the data link joins each mobile node with at least one access point on a 
Spread Spectrum band. At least some of the access points arc located adjacent a roadway. 

Preferably, the system includes a measuring module for measuring impedance on each 
of the data links. In this case, the switching unit is operable to select the data link having the 
least impedance. 
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In still another of its aspects, the present invention provides a communications network 
for exchanging data between a plurality of vehicles, comprising a computing unit onboard a 
corresponding vehicle, each computing unit being operable in a fast phase to broadcast enquiry 
messages in a region surrounding the vehicle, a second phase to receive reply messages from 
other vehicles in the region, and a third phase to exchange status messages with selected ones of 
the other vehicles. 

In one embodiment, each computing unit includes an IEEE 802.11 node and exchanges 
data using an SNAP-derived Protocol. Desirably, each node is Internet addressable, such as by 
the IM standard for example. 

In still another of its aspects, the present invention provides a vehicle comprising an 
onboard computing unit which is operable in "a first phase to broadcast enquiry messages in a 
region surrounding the vehicle, a second phase to receive reply messages from computing units 
of other vehicles in the region, and a third phase to exchange status messages with computing 
units of selected other vehicles. 

Preferably, the vehicle is operable in a fourth phase to exchange data with a remote site 
in the form of a network gateway, which routes communications between a wireless mobile 
data link and a non-mobile network. 

In one embodiment, the computing unit includes an IEEE 802.1 1 node and can 
exchange data with other computing units using an SLANT-derived protocol. 

In still another of its aspects, the present invention provides a hybrid 
communications system, comprising a wired network portion and a wireless network 
portion, each having a network connection node, at least two data link means between the 
network connection nodes, and a switch means for enabling either of the data links for data 
exchange between the connection nodes. 
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Preferably, the system further comprises measurement means for measuring 
impedance on the data links, the switch means being responsive to the measurement means 
for enabling the data link having a lower impedance. 

In yet another of its aspects, the present invention provides a vehicle communications 
system having a controller, a data pathway joining the controller wit h f a plurality of vehicle 
components and means for establishing a data link with other vehicles within a given region 
surrounding the vehicle in order to exchange data therewith. 

In still another of its aspects, the present invention provides an operational event- 
reporting system for use by a plurality of neighboring vehicles to support IVHS comprising a 
plurality of communication units, each onboard a corresponding vehicle to collect operational 
data from selected components thereof and to exchange data with the communication units of 
one or more of the neighboring vehicles. 

Preferably, the system is capable of exchanging data related to the operation of the 
neighboring vehicles, for example, GPS position and heading, vehicle speed, braking or the 
like. Dataof this kind can be useful for vehicle telemetry systems to provide such things as 
collision avoidance, for example. 

In yet another aspect of the present invention, there is provided a method of exchanging 
data between a vehicle and at least one data exchange site, comprising the step of providing the 
vehicle with a transmitter and receiver capable of transmitting and receiving messages under the 
SNMP protocol. Preferably, the data exchange site includes a neighboring vehicle or an access 
point for a wired network, for example. 

In one embodiment, the method further comprises the steps of 

- exchanging discovery signals with neighboring vehicles; and 

- exchanging status data with selected ones of the neighbouring vehicles 
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In yet another of its aspects, these is provided a system for transferring data between a 
vehicle and another data exchange site, comprising a pair of data link means, wherein at least 
one of the data link means has a varying signal impedance level and switch means for switching 
between the data link means so that the data is transferred on the data link means having the least 
impedance. 

The Applicant's pending application, serial number 09/140,759 filed August 26,1998 
entitled SYSTEM AND METHOD FOR PROVIDING MOBILE AUTOMOTIVE 
TELEMETRY discloses a system and method for automotive maintenance telemetry. The 
system functions on a client-server architecture enabling a remote client to request information 
from an onboard diagnostic (OBD) module in a vehicle, such as that commonly referred to as the 
Electronic Control Module (ECM). The OBD module performs the role of 'server* by being 
programmed to interface with the ECM, and with any other sources of diagnostic information 
and then communicates the data to a requesting client, such as OEM suppliers, dealers or 
regulatory agencies. 

The location of the requesting client can dictate how the data is delivered. For 
example, in the Applicant's co-pending PCT Application PCT/CA98/00986 filed October 23, 
1998 entitled TELECOMMUNICATIONS SYSTEM, the OBD module may select a path of 
least impedance to deliver the data to the client. For example, where the client is land-based, 
such as, for example an emissions regulatory body, the OBD module may deliver the data 
either through a conventional RF packet network (such as over a cellular phone connection) 
or through an RF packet network using a Hybrid network as described in the above 
mentioned PCT application. However, the requesting client may in fact be another vehicle 
traveling along the same roadway as the server vehicle and may request data for such things 
as vehicle speed, braking, position and the like. The OBD module may convey the data over a 
wireless data link such as over the band known as the "Spread Spectrum Band" as is 
described in the applicant's co-pending provisional application serial number 60/139,573 tiled 
June 17, 1999, entitled VEHICULAR TELEMETRY and as specified in the IEEE 802.11 
standard. 

IEEE 802 Standards Family 
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The EEEE 802 family of standards specifies the methods for implementation of local 
area networks (LAN's) using both wired and wireless media. The EEEE 802.1 1 standard 
specifies the medium access control (MAC) layer and three separate methods for 
implementation of the physical layer (PIM as a wireless medium. IEEE 802.11 is intended to 
ensure inter-operability between multi-vendor equipment operating in wireless networks. As 
such, it is the basis for the interface specified herein enabling vehicular computing equipment 
to establish license-free data links with, fixed stations. 

The IEEE 802.1 1 standard specifies three different Physical layers, use oflnfrdrcd light, 
Direct Sequence Spy Spectrum and Frequency Hopping Spread Spectrum_ The band utilized 
for the Spread Spectrum technique is ISM (Industrial, Scientific and Medical) RF band, which 
is free of regulatory licenses in most of the world. Communications in the Spread Spectrum 
involve a coordinated change in frequencies, either by a "Direct Sequence" or a "Frequency 
Hopping" format. Though the specific nature of these formats is not relevant for the purposes 
of the present invention, it is merely important to realize that they exist. 

The IEEE 802.2 standard, called Logical Link Control (LLC), specifies a method for 
addressing and control of the data link; independent of the underlying medium, and is 
applicable to all types of LAN's defined within the IEEE 802 family. Both 802.1 1 and 802.2 
are incorporated herein by reference. 

The IEEE 802.1 1 does not. specify the handoff mechanism for a mobile node to roam 
from one Access Point to another. When both the IEEE 802.11 client and Access Points 
incorporate IPv6 implementations, including ND and RD, roaming clients are able to bind to 
(or to establish a data link with) the Access Points, where the latter take on the role of 
Foreign Mobility agents as defined in [3], The Access Point acts as a mobility agent for the 
roaming client. The Mobile IP specification therefore provides a solution to the lack of an 
IEEE 802.1 1 mechanism for coordination of roaming (handoff) between Access Points. 

Automotive Telemetry protocol 
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In one embodiment, data is exchanged between vehicles using a protocol herein 
called "Automotive Telemetry Protocol 11 (or ATP) and is based on Simple Network 
Management protocol (or SNMP). The latter is commonly used in data communication 
networks to monitor and control switching equipment. SNMP is specified in [2], the 
contents of which are incorporated herein by reference. ATP is intended to function 
according to the same client-server model as SNMP, wherein the client issues the requests for 
information and the server issues the responses. Although the ATP makes use of the same 
formats of the requests and responses as SNMP, ATP implements a novel set of "object 
identifiers" which are required to encompass the OBD data requested, in contrast to the 
telecommunications equipment data exchanged in SNMP. For example, the object 
identifiers may, in this case, correspond to nodes on the Controller Automation Network 
(CAN) bus in the vehicle, such as the ABS system, emission control system and the like. 

SNMP and its derivative defined herein, ATP, are efficient request-response 
mechanisms which require less bandwidth than Web-based data exchanges between client and 
server. The payload (i.e. the useful telemetry data) can be encapsulated within the maximum 
allowable frame sizes of the underlying data links. These protocols therefore do not require the 
overhead associated with fragmentation at the source, and properly sequenced reassembly of 
large messages at the destination. 

IPv6 and Mobile IP: Dynamic topology of the new Internet 

The well known "Mobile IP" specification defines a protocol that enables IPv6 
datagrams to be transparently routed to mobile nodes in the Internet. This specification is 
provided in Internet Engineering Task Force, Perkins, C (ed), " IPv6 Mobility Support'; 
March 1995 [3], the contents of which are incorporated herein by reference. 

By definition, a mobile node is one that can connect to the Internet through any one of 
a variety of different access points, called mobility agents. Each mobile node is registered 
with one and only one mobility agent, called a home agent. When a mobile node attached 
itself to the Internet through an access point other than its home agent, the access point is 
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called a foreign agent. The Mobile IP protocol incorporates a mechanism for mobile nodes, 
when they are attached to a foreign agent, to register a "care-of-address" with the home agent. 
Thus, diagrams routed to the mobile node through the home agent can be re-routed to reach 
the mobile node at its current network location. 

When a mobile vehicle is already equipped with radio-modem technology that provides 
a unique address on a wireless network, it is possible to assign a unique Internet address that 
can be reached through an IP router between the wired Internet and the wireless network. . This 
is described in the Applicant's co-pending PCT Application PCT/CA98/00986 filed October 
23,1998 entitled TELECOMMUNICATIONS SYSTEM. This represents a static Internet 
topology because, although the vehicle is mobile, the IP router through which it is reached 
never varies. The topology of the wireless network itself is dynamic and supports the roaming 
required for a vehicle to establish contact with the network through different base stations and 
regional switches. However, at the IP level, this dynamic topology is not visible. 

In contrast, the Mobile IP extension to the IM specification allows for a dynamic 
network topology. It lends itself to the task of enabling communication from the Internet to a 
mobile vehicle through different foreign mobility agents. In the context of vehicular mobility, 
the role of mobility agent can potentially be adopted by any Internet node that has the ability to 
dynamically create a data link with a vehicle. To date, the most efficient means available by 
which such data links can be quickly established are defined by the IEEE 802.1 1 specification 
for wireless LAN's (Local Area Networks). 

A data link can be established between a mobile IEEE 802.11 node, implemented in 
the vehicle, and any fixed IEEE 802.11 node, called an Access Point, provided that both 
nodes incorporate full implementation of the IPv6 protocols, specifically the Neighbor 
Discovery protocol, (hereinafter referred to as ND) and the Router Discovery protocol (RD). 
ND and RD are specified in Narten; T., Nordmark, E:, and W., Simpson, "Neighbor 
Discovery for IP Version 6 aPv6)" RFC 1970, August 1996.(5], the contents of which are 
incorporated herein by reference. For every interface to a datalink implemented in an EM 
node, in this instance a wireless IEEE 802 datalink, ND is required to ensure that neighbors, 
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defined as other nodes which are "on-link" (i.e., capable of communications on the same 
datalink) can be dynamically identified as they appear. This is accomplished through the use 
of periodic broadcasts on the wireless medium, called Neighbor Solicitations, to which any 
recipient of the broadcast is required to respond, in such a way as to enable the broadcaster 
to identify the responder with a unique IM address. An implementation of ND typically 
maintains a table of neighbors that dynamically changes as each new cycle of neighbor 
solicitation either reveals a new respondent or loses, through lack of response, a 
(previously) existing neighbor. RD is a specialization of ND, ensuring that on-link nodes 
capable of routing IP datagrams to other sub-networks, can be discovered. 

Thus, the vehicle communications system, according to one embodiment of the present 
invention, is capable of handling the Mobile IP protocols over an IEEE 802.1 1 data link and, as 
a consequence, is capable of delivering vehicular diagnostic data under the requirements of 
OBD-III and of exchanging a wide range of data, including ecommerce transactions and the 
like, as well as data needed for such things as Intelligent Vehicle Highway Systems. 

According to one aspect of the present invention, each vehicle has one of a number of 
Hybrid Network Radios (as described in Applicant's PCJ 'patent application PCT/CA98/00986) 
which can effectively communicate with one another using the Mobile IP protocol over one or 
more wireless LAN's. In this particular case, then, Internet-addressable vehicles may roam 
between wireless LAN's and still be in the network. 

Ad Hoc Network 

By making the vehicular computers Mobile IP-enabled as described in utility patent 
application 09/140,759 filed August 26, 1998 (entitled SYSTEM AND METHOD FOR 
PROVIDING MOBILE AUTOMOTIVE TELEMETRY), each vehicular system may be 
connected to the Internet through the IEEE 802.1 1 data link. When two or more vehicular 
computer systems are equipped with IEEE 802.1 1 interfaces and where each operates on the 
same frequency changing format, that is by using either Direct. Sequence Spread Spectrum or 
Spread Spectrum Frequency Hopping, they can then communicate amongst themselves and 
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thereby create an "ad hoc" network between them. The so-equipped vehicular systems can 
now support IP Neighbor Discovery, which enables all vehicles within range to recognize 
each other as "on-link" IPv6 nodes, provided that the adjacent vehicular systems are also 
compliant with IPv6. Thus means that useful information maybe exchanged between 
adjacent vehicles by the use of Spread Spectrum frequencies. Therefore, the same UDP/EP 
mechanism, used to permit telemetry traffic to be encapsulated in IPv6 datagrams from any 
vehicle to a fixed-location host, can be used to permit telemetry traffic to be exchanged 
between vehicles. 

This ad hoc network also enables mobile vehicles within range of each other to 
establish a "cluster intelligence", which is defined, within the context of the present 
invention, as an infrastructure for interactive vehicular control based on the same 
request/response telemetry architecture described in utility patent application serial number 
09/140,759 filed August 26, 1998 (entitled SYSTEM AND METHOD FOR PROVIDING 
MOBILE AUTOMOTIVE TELEMETRY). 

In one embodiment, the system comprises the following components: 

(1) Hybrid Network Radio, as specified in (4), supplemented by: 

(a) Wireless LAN interface compliant with: 

(i) IEEE 802.2 

(ii) IEEE 802.11 interface 

(b) IPv6 modules including: (i) IPv6 

(i) IPv6 

(ii) IVMPv6 

(iii) IP Neighbor Discovery and Router Discovery 

(iv) Mobile IP 

(2) IEEE 802 Access Point as an IPv6 Router 

(3) Cluster Intelligence Module 



Doc #:WAS01 (213407-0001 1) 41499971 vl:07/08/2003/Time: 17:59 



12 



. Substitute Specification- Marked-up version 

The cluster intelligence module is intended to provide a means by which intelligent 
Vehicle Highway Systems (IVHS) can be implemented without the need for electronic 
wiring of the highway infrastructure. Cluster, intelligence is based on the establishment of an 
ad hoc network connecting vehicular Hybrid Network Radios. Whereas the primary goal of 
the Hybrid Network Radios is to enable least-cost IPv6 communications of telemetry data 
required by environmental regulations, an ad hoc network among and between Hybrid 
Network Radios provides a platform on which vehicles can transmit real-time operational 
information to each other. 

As a result, in those instances where the aim of NHS is to control the spacing and speed 
of vehicles on highways, and therefore the volume of vehicular traffic flow, cluster intelligence 
offers a low-cost alternative to the conventional ideas proposed for highway infrastructure 
upgrades. 

Figure A shows the classic relationship defined in traffic engineering between speed 
and volume on a road link. There is an optimum point along this curve where the volume is 
maximized. The speed at thus point is defined as the "free flow" speed. Below this speed, 
traffic flow is conjested. Above this speed, the spacing between vehicles required for safety 
results in profligate use of the roadway- At any point along the curve, the volume-speed 
relationship represents the most efficient inter-vehicle spacing, given the braking distance 
required for safety, which can be achieved. 

In one embodiment of cluster intelligence, the peer-to-peer telemetry architecture of [1] 
Supports the ability of vehicles to adapt their speeds in accordance with the optimal volume- 
speed relationship. ATP used between vehicles enables each one to determine; 

(a) The distance(s) between it and the vehicle(s) immediately ahead of it (using GPS 
position and heading reports). 

(b) The speeds) of the vehicles immediately ahead of it. 

(c) Application of brakes. 



Doc #:WASOI (213407-0001 1) 41499971 vl;07/08/2003/Time: 17:59 



13 



. Substitute Specification- Marked-up version 

This information provides the enabling technology for all vehicles to engage in a cooperative 
effort to maximize traffic flow on electronically enhanced highways. 

The tem "Impedance" used herein is intended to be a measure of the "costs" of 
sending a datagram across a data link. This cost can include the monetary charges associated 
with the transmission of data across a wireless data link and are typically imposed by the 
operator of the wireless data network, as well as other factors such as, for example, the size of 
packet and the time of day, which of course will change over time. As is described in the PCT 
Application serial number PCT/CA98/00986 filed October 23, 1998 entitled 
TELECOMMUNICATIONS SYSTEM, the Impedance governs the functionality of the RF path 
switch. As impedance chang es , the output of the RF path switch (i.e. the muting decision) can 
change. The sections entitled Error Reporting and Airlink Status Reporting describe the 
mechanisms whereby changes in impedance are reported to the RF path switch module. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Several preferred embodiments of the present invention will be provided, by way of 
example only, with reference to the appended drawings, wherein: 

Figure A is plot of traffic volume versus speed on a road link; 
Figure 1 is a schematic view of a vehicle communications system; 

Figure 1 a is a schematic view of one aspect of the vehicle communications system of 
figure 

Figure 2 is another schematic view of the vehicle communications system of figure 

i; 

Figure 3 is a schematic view of one segment of the vehicle communications stem of 
figure 1 ; 
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Figure 4 is a schematic view of another segment of the vehicle communications system of 
figure 1; and 

Figure 5 is a schematic view of still another segment of the vehicle communications system of 
figure 1. 

FIG. 6 is schematic representation of a system in accordance with one embodiment of the present 
invention. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

Figure 1 illustrates a communications network for exchanging data between a 
plurality of vehicles, including vehicles 10 and 12 on a highway shown at H. Each vehicles 
has a computing unit 10a and 12a, the latter of which is shown schematically in figure la. 
Each computing unit has a processorlOc which is connected via a serial port to a GPS unit - 
lOd which is capable of receiving satellite GPS signals, an IEEE 802.11 Spread Spectrum 
unit lOe capable of broadcasting and receiving data over a Spread Spectrum data link, a cell 
packet data unit lOf capable of broadcasting and receiving data over a cell packet data 
network and a memory unit lOg. If desired, the components of the computing unit may be 
chipset as specified in U.S. provisional application serial number 60/148,270, filed on 
August 11, 1999 and entitled VEHICULAR COMPUTING DEVICE. 

Referring to figure 1, each computing unit 10a, 12a broadcasts ND and RD messages 
in a region surrounding the vehicle as shown by the circles 1 Ob, 12b. In the example shown 
in figure 1 three other similarly equipped vehicles labeled 14a to 14c are all within the region 
1 Ob and therefore are capable of receiving the broadcast enquiry messages from the vehicle 
10. The vehicles 14a to 14c issue reply messages which are received by the vehicle 10. 
Similarly, vehicles 14b to 14f are within the region 12b of the vehicle 12 which in turn 
receives reply messages from them. These messages may include such things as vehicle 
speed and GPS information as well as status indicators such as acceleration or braking. In 
this manner the computing units 10a, 12a are able to determine the position and movements 
of neighboring vehicles. 
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Thus, the number of vehicles in the corresponding region for each vehicle will change 
over time with the traffic pattern. In this case, the computing unit for each vehicle can retain 
status data for each target vehicle while the vehicle is in the region and then erase the data 
for those vehicles that have left the region. The memory unit lOg can have allocations for 
storing data for each vehicle while the processor can manipulate the data to determine if any 
action needs to be taken. The processor also receives data from the ECM lOh which can 
include such things as emissions, braking, acceleration, speed and the like, that is, any 
function of the vehicle which is being electronically sensed, monitored or measured. The 
processor may also be coupled with a braking override lOi or other override lOj for controlling 
the vehicle if necessary. 

Located along the highway are a number of access points which are routers to a fixed 
communications network, in this case Spread Spectrum base stations. One of the access 
points is shown at 16. The access point 16 issues router advertisement messages with a region 
shown by the circle 16a. Therefore, vehicle 12, in the instant of time represented by the 
figure 1, receives the advertisements. In this example, the vehicle computing units 10a and 
12a as well as the access point 16 are IPv6 addressable. Therefore, the vehicle 12 and the 
access point 16 may then exchange data which may include Internet email and the like. The 
access point 16 may also convey status request data from a clean air regulatory body to the 
vehicle 12 which may then return the status data to the regulatory body through the access 
point 16 if the vehicle is still in its region. 

Located near the highway is an RF packet network base station 1 8 such as a relay tower 
or the like which broadcasts on a data link such as a proprietary RF packet network, for 
example that known as the MOBITEX network, or the like. This is a different data link form that 
Spread Spectrum data link operating at the access points 16. The computing units exchange data 
with the station 18 via the cell packet data unit lOf 

The GPS information from the neighboring vehicles may, for example, include 
Differential GPS (D-GPS). In the latter cases, the vehicle may more accurately measure the 
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position of neighboring vehicles, relative to a reference GPS position which may be broadcast, 
for example, from the access point 16. 

Global System 

Figure 2 shows the overall system architecture. As will be described, Figure 2 illustrates 
how the IEEE 802 data link is incorporated into the hybrid mobile packet network an d shows the 
path of Mobile EP communications between a mobile node shown at 10 and its home mobility 
agent, i.e., the Hybrid Network Gateway 230. Mobile node 10 is an embedded vehicular 
computing device functioning both as an OBD server [1] and as a Hybrid Network Radio [2], 
The Hybrid Network Radio functionality is implemented through the interface 40 to the hybrid 
mobile packet network 250. 

Fixed node 16 is a wireless communications base station implemented in accordance 
with the definition of a "foreign (mobility) agent" contained in [3]. Mobile node 10 and fixed 
node 16 share the same IEEE 802 wireless data link 15, which, from the perspective of the 
mobile node 10 and as will be described further below, is integrated as a "zero-cost" data link 
in the interface 40 to the hybrid mobile packet network 250. Fixed node 16 may be, for 
instance, an embedded computing device permanently installed near a roadway and 
connected to a data communications network 210 via a stationary (non-mobile) backbone 220. 
When a mobile node 10 comes sufficiently within range of a fixed node 16 to establish an 
IEEE 802 data link, Internet traffic, in the form of IP datagrams, may flow from the vehicle to 
any address in the Internet. This is called "mobile-originated" traffic. "Mobile-terminated" 
traffic can only reach the vehicle once the Mobile IP "care-of address" registration has been 
completed. This procedure; specified in [3], allows the mobile node to notify its "home 
(mobility) agent', that it can be reached through the foreign (mobility) agent embodied in the 
fixed node 16. As a foreign (mobility) agent, fixed node 16 is, by definition, an IPv6 router. 

The home mobility agent for mobile node 10 resides in the Hybrid Network Gateway 
230. A Hybrid Network Gateway (HNG) is the stationary equivalent of a Hybrid Network 
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Radio and is defined in [2]. HNG 230 has an abstract interface 240 to the hybrid mobile 
packet network 250, through which it can route Internet traffic to a mobile node. In order to 
ensure least-cost routing to a mobile node that has registered fixed node 16 as its care-of- 
address, interface 240 must also incorporate the data link associated with stationary backbone 
220. This extends the hybrid mobile packet network to include a stationary data link. 

In other words, the system has the capacity to carry out least-cost transfer data between the 
Hybrid Network Gateway 230 and the mobile node 10 in one of three routes: 

i) via the data link 15, the fixed node 16, the datalink 220 and the stationary non-mobile 
data link 210; or alternatively 

ii) through the hybrid mobile packetnetwork 250, which itselfcan provide least cost 
switching between 

a) a satellite Packet Network; or 

b) an RF Packet Network. 

Ipv6 Communication Protocol Stack 

The EPv6-based communications software infrastructure for a telemetry system in 
accordance with this example is shown in Figure 3. Figure 3 is a representation of the Hybrid 
Network Radio incorporating interfaces to an arbitrary number of RF packet networks, including 
an interface to a wireless IEEE 802 data link, integrated into a single abstract data link as 
specified in [4]. Figure 3 also shows the relationship between the Hybrid Network Radio and an 
IEEE 802.11 Access Point incorporating an IPv6 router implementation. In this scenario, 
mobile-originated Internet traffic (datagrams emanating from the Hybrid Network Radio) can be 
routed through the access point or alternatively through the hybrid mobile packet network 250 
depending on cost. Mobile node 10 is an IPv6 (Internet) node consisting of a protocol stack 20 
in accordance with definition of a Hybrid Network Radio provided in [4]. Fixed node 16 is an 
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IPv6 (Internet) router consisting of the router-specific equivalent of protocol stack, labeled 21. 
The components of protocol stack 20 are: 

(i) a combined RF packet network 30 that unifies all the wireless data links available 
to mobile node 10 into a single abstract data link capable of least-cost switching; 

(ii) an IPv6 module 60, in accordance with [6], the contents of which are incorporated 
herein by reference; 

(iii) an IPv6 module 70, in accordance with [7] the contents of which are 
incorporated herein by reference, that provides the assembly and parsing mechanisms for the 
specific datagrams required by ND; 

(iv) a Neighbor Discovery (ND) module 80, in accordance with [5], that enables 
mobile node 10 to dynamically discover other "on-link" mobile nodes, i.e., other vehicles 
capable of communicating on the same IEEE 802.1 1 medium; and 

(v) a Router Discovery (RD) module 90, in accordance with [5], which enables 
mobile node 10 to discover dynamically IM router 16. 

Both the ND and the RD protocols require the broadcasting of, respectively, neighbor 
and router advertisement datagrams, defined in ICMpv6. These datagrams are sent to the 
interface 40 to the combined RF packet network 30. Broadcast datagrams can only be 
transmitted on data links that are broadcast-enabled. Typically, wide area RF packet networks 
do not support broadcasting, although they often allow multicasting to selected groups of 
mobile subscribers. Since IEEE 802.11 depends on broadcast frames to establish the data link, 
it should identify itself to interface 40 as broadcast-enabled, whereas all other RF packet 
networks incorporated in the combined packet network 3 0 should report that they are not 
broadcast-enabled. The intelligent switching mechanism of this interface, which ensures that 
datagrams are transmitted over the least-cost data link, will therefore switch all mobile- 
originated broadcast datagrams over the IEEE 802.1 1 data link. 

In case of overlapping of the coverage areas of two or more Access Points, a mobile 
node may receive router advertisements from more than one fixed station, in response to its 
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broadcast of router solicitations, providing it with alternative on-link routes to use for 
outbound datagrams. Contrary to the recommendation in [5], mobile nodes should avoid the 
use of router.and neighbor solicitation datagrams, in order to minimize the amount of 
contending traffic on the data link. Both neighbor and router discovery should rely primarily 
on unsolicited neighbor and router advertisements. 

Registration of the "care-of-address" provides a means for requests from the OBD 
telemetry client to reach a mobile node via the foreign mobility agent, which, by definition, is an 
EEEE 802 access point. The impedance values of these requests can beset such that the mobile- 
terminated ATP traffic that would otherwise incur costs traveling over RF packet networks, can 
be deferred until the "care-of-address" is registered with the home address. 

Cluster Intelligence 

The cluster object as an ATP client is a specialization of the generic SNMP client using 
the UDP/IP Protocol. The ATP allows for message passing to the cluster object. 

The establishment of an EEEE 802.11 ad-hoc network as a "mobile cluster" in accordance 
with the present example is shown in Figure 4. Mobile node 10 incorporates the User Datagram 
Protocol (UDP) module 100 and the ATP module 1 10. An equivalent mobile node 11, with 
equivalent UDP and ATP modules 101 and 111, respectively, can interact with mobile node 10 
such that the automotive behavior of 11 is known to 10. This is accomplished through the 
mechanism of an ATP request issued by 10 to 1 1 and an ATP response from 1 1 to 10. 

The interaction between any two mobile nodes is managed by a "cluster", which is an 
active object that registers with the ATP for reports from neighboring vehicles. Cluster 120 has 
container 130 of neighbors, or more precisely, "images" of neighbors. These neighbors are 
placed in the container when detected by the ND mechanism operating over the MY 1: 802.11 
data link, as shown in Figure 4. By propagating the discovery mechanism in ND module 90 
upwards through the UDP/IP stack, Node 1 1 becomes a member of Node 10 f s cluster when the 
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ATP signals the cluster that a new neighbor has appeared. (The whole process can be repeated 
for mobile node 12, which becomes a second neighbor of node 10). 

Registration of neighbors discovered through the ND requires an implementation of IPv6 
that can be asynchronously notified of ND, which requires a "callback" method of IPv6 to be 
invoked when the neighbor's response to a solicitation request is being processed. The 
conventional processing of such a response is simply to update the cache of on-link neighbors 
known for that interface. However, the requirements of cluster intelligence are that dynamic 
neighbor identification propagate upward from the subnetwork layer to an application port of the 
UDP/IP protocol stack. 

In this example, cluster communications over wireless data links is intended to take place 
only over the license-free Spread Spectrum band. The cluster object itself has "no knowledge" of 
the fact that there are alternative radio paths between vehicles. However, when the cluster asks 
each new neighbor to transmit GPS position reports and automotive events in which it is 
interested, both the requests as well as the responses will travel only over zero-cost links - 
which are precisely the same links over which the ND operates. In others words, by virtue of the 
least-cost mechanism described in [4], a license-free wireless data link will always be the data 
link over which the ND datagrams are transmitted. ND can and should be configured such that 
its maximum acceptable impedance level can only be supported by the license-free links. ND 
will therefore only discover neighbors that are on the license free links and cluster traffic that 
follows from this will travel only over these links. 

Piovided that an implementation of cluster 130 is compliant with the requirements for the 
interface to the module ATP 110, already specified in [1 ], the internal behavior of the cluster 
may vary depending on the design objectives and implementation style for a specific vehicular 
device. The precise design of the methods (behavior) or the specification of other methods 
intended to process (and act on) information reports from neighboring vehicles is not within the 
scope of the present invention. 

Process Architecture 
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Figure 5 illustrates the process architecture of the device comprising the mobile node. 
ATP client process 300 is part of the cluster intelligence module. Figure 5 illustrates the 
architecture of the processes, running on top of the UDP/1P stack, that provide all of the 
functionality of the system. These processes are: 

(i) an OBD process, with the behavior of an ATP server; 

(ii) a Cluster Intelligence process with the behavior of an ATP client; 

(iii) a Mobile JP process, with the behavior specified in [3]; and 

(iv) a diagnostic data acquisition process. 

ATP is registered with UDP module 330 through the application port305. Similarly 
Mobile IP process 310, which is responsible for registration of cam-of-addresses (i.e., addresses 
of foreign mobility agents) with home mobility agents, is registered with UDP module 330 
through the application port 315. The ATP server process 320, registered with UDP module 330 
through port 325, provides access to the Diagnostic Information date Base (DIB) 340. This data 
base, similar to the Management Information data Base (MiB) used by SNMP (from which ATP 
is derived), contains all of the on-board diagnostic information obtained from the data acquisition 
processes 350 (Analog and digital signal processing), 360 (CAN-bus data processing) and 370 
(GPS receiver data processing). 

Whereas the present invention does not limit the scope or characteristics of possible 
cluster implementations, the behavior recommended for effective use of the ATP to implement 
cluster intelligence within each vehicle is described by the pseudo-code below. The cluster is 
defined as an object that owns an ATP client process with a set of methods corresponding to the 
handling of each of the possible messages that could be received through the ATP. 

The cluster's ATP client process would be: 
ClusterProcess () 

{ 

while(TRUE){ 
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<i * 

pointer _ event ^object = Wait jQueue Event _ Signalled _By_ ATPQ; 
pointer _ event _object->Handler(); //behavior of event object 
destroy _ event(pointer _ event _ object-) 

} 

The cluster process blocks on an event queue, registered with the ATP, to which the ATP 
can append events relevant to the cluster process as they occur. These events are removed from 
the queue and processed on a first-in first-out basis. All events are treated as objects derived 
from a common base class within a virtual "handler" method, the internal behavior of which 
varies for each type of event. The handler method of the event is invoked by the cluster process 
when the event is removed from the queue. 

The primary type of event which the ATP should signal to the cluster is a GPS position 
report from a neighbor. This implies, of course, that all nodes on'the ad-hoc IEEE 802.11 
network should broadcast GPS position reports. Other on link nodes receiving these broadcasts 
should propagate the reports upward through the protocol stack to the ATP, which should signal 
an Events GpsReport to the cluster. Event _GpsReport_Handler () is the method invoked 
when the GpsReport signaled by the ATP is removed by the cluster process from its queue. The 
inputs to this method are: 

(i) ID Remote-Vehicle - which should be the unique TP address of the vehicle; 

(ii) GpsPosition - which is a latitude-longitude coordinate pair, determined by the 
GPS receiver of the remote node and contained in the payload of the UDP segment received 
from the remote; and 

(Hi) GpsHeading-which is a heading determined by the GPS receiver of the remote 
node and contained in the payload of the UDP segment received from the remote. 

Event GpsReport Handler (ID-Remote.Vehicle, GpsPosition, GpsHeading) 
Remote Vehicle = GetRemote(LD Remote_ Vehicle); 

Proximity - CompareGps (Remote Vehicle, GpsPosition, 

GpsHeading); If (Proximity) { 
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AtpRequest(Remote Vehicle, speed frequency, duration, amplitude); 
AtpRequest(RemoteUehicle, foot brake, 0, 0, 0); 

Event GpsReport Handler carries out the following functions; 

(i) Invokes the private function GetRemote using the input ID Remote_ Vehicle. (The 
term private signifies that the function is usable only by the cluster module and is not 
accessible to C "external" software modules). This searches the cluster's container of remote 
vehicles for the object matching ID Remote Vehicle; 

(ii) Uses the private function CompareGps to determine whether this vehicle is 
within a specified distance threshold. This function takes as inputs; 

(a) Pointer to the Remote Vehicle object; and 

(b) the new GPS position and heading. 

The GPS position and heading of the remote vehicle are compared to the position and 
heading of the "local" vehicle, The "local" position and heading are maintained in the DIB 
(diagnostic information base). Since the ATP is a peer-to-peer protocol, cluster intelligence 
request/response exchanges can be symmetrical. The DIB can therefore be used by the ATP 
client to obtain GPS information for comparison with reports from remote nodes, as well as 
by the local OBD server to respond to cluster intelligence requests from remote nodes. 

The output of CompareGps a boolean variable {Proximity) indicating whether ATP 
requests to this remote are warranted because the vehicle is within a specified distance threshold 
to require preventive measures if there is a sudden change in speed-. Since the 
implementation of cluster intelligence is not within the scope of the present invention, the 
internal algorithm of CompareGps is not defined here. However, it should be noted that any 
implementation of CompareGps must account for margins of error in the accuracy of the 
GPS receiver where the remote position report originates. Furthermore, it may not be possible 
to distinguish between several remote vehicles moving in parallel in different lanes ahead of the 
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"local" vehicle so that the identity of the vehicle directly in front may remain indeterminate. The 
cluster intelligence decision algorithm may have to assume that all of these vehicles are equally 
important to monitor. 

If Proximity is TRUE, then ATP requests can be issued to the remote node's OBD server, 
the responses to which enable the cluster to provide decision support to other intelligent modules 
within the complete automotive system, q minimum se t of requests could consist of speed reports, 
at values of frequency and duration established by the owner of the cluster, (i.e., one of the 
aforementioned automotive modules), and of notifications for the application of the foot brake. 

A mobile automotive telemetry system in accordance with the present invention is shown 
schematically at 610 in FIG. 6. System 610 comprises a diagnostic means 615 for monitoring the 
operational functions of the vehicle in which system 610 is installed and generating operational 
information. The generated operational information may be stored in a memory 620 until 
required. Both diagnostic means 615 and memory 620 are in communication with a server 625 
which ultimately controls the operation of system 610. 

Server 25 can communicate with a remote client 630 via a data link 635. To this end, server 625 
comprises a means (640) to receive a request for information from remote client 630; a means 
(645a, 645b) to retrieve the generated operational information from memory 620; and a means 
(650) to transmit the retrieved generated operational information to remote client 630. Server 625 
is a processor which is programmed to respond to requests for information from remote clients 
and to respond to control commands. 

Diagnostic means 615 may be a conventional, computer-based OBD module which monitors 
various operational functions of the vehicle in which system 610 is located. Diagnostic means 
615 may, for example, monitor exhaust emissions, fuel use, ignition timing, engine temperature, 
speed and/or distance travelled. Diagnostic means receives inputs from the various vehicle sites 
via a plurality of communication lines 660 and, after interpreting the inputs and generating 
formatted operational information, passes the operational information to memory 620 via 
communication line 665. Diagnostic modules suitable for use in the present invention are known 
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in the art and are referred to as Electronic Control Modules (ECM) or Electronic Control Units 
(ECU). The specifications for the diagnostic modules may be found in Society of Automotive 
Engineers, "On-Board Diagnostics for Light and Medium Duty Vehicle, Standards Manual" 
1997 Edition, the contents of which are incorporated herein by reference. 

Memory 620 may be any conventional computer memory, the size and operation of which will 
be dependent on the nature of the operational features of the vehicle a user wishes to monitor. 
The choice of suitable memory is believed to be within the purview of a person of skill in the art. 
In a presently preferred embodiment of the present invention, system 610 comprises a memory 
620 which includes 32 k of nonvolatile RAM and a configurable amount of additional RAM, 
allocated at run-time from the host processor system. Memory 620 receives the operational 
information, generated by diagnostic means 615, via communication line 665 and stores the 
operational information. Memory means 620 is in communication with server 620 and is capable 
of receiving instructions from server 625 and sending information to server 625 via 
communication lines 670a and 670b, respectively. As will be apparent to a person of skill in the 
art, communication lines 670a and 670b may be replaced by a single communication line if the 
appropriate communication protocol is used. 

Server 625 acts as a gateway between remote client 630 and diagnostic means 615 and 
eliminates the requirement that remote client 630 has knowledge of the specialist QBD protocols 
of diagnostic means 615. Server 625 in effect acts as a "universal translator", allowing a remote 
client to interact with any diagnostic means of any vehicle. One way of achieving this end is 
through the implementation of a request/response protocol which acts as a proxy for the 
corresponding QBD protocols. Under this type of protocol, an abstract request from the remote 
client which is received by the server is mapped to the corresponding request under the specialist 
QBD protocols and is then transmitted on the diagnostic means or memory, as appropriate. In the 
other direction, the responses returned by the diagnostic means or memory to the server are then 
ma pped to an abstract response which is sent back to the client. 

Such request/response protocols are known in the art and include, for example, IAS protocol for 
infrared links and UDP/IP protocol for wide area network communications. 
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Data link 635 may be any conventional communication link, including, for example, telephony 
(wired and mobile wireless), specialized mobile radio (SMR), infrared and satellite (both low 
earth orbit (LEO) and geosynchronous). Server 625 may be provided with the hardware and 
operational protocols necessary for communicating with remote client 630 by a variety of means, 
thereby not restricting communication to a remote client having one particular type of data link. 
Providing server 625 with a plurality of communication protocols aids in making the system of 
the present invention universally acceptable. 

In a presently preferred embodiment, server 625 is provided with infrared data link capabilities. 
An infrared data link between the server and the remote client provides a local wireless method 
of acquiring data from an OBD module. It therefore removes the need for the client's equipment 
to incorporate a system-compatible connector (i.e, an OBD-connector as specified by the SAE) 
and to be physically joined by a cable in order to communicate with the system. 

When, for example, the client is test equipment in a garage, the use of an infrared data link 
renders possible the development of service bays where information can be transferred almost 
instantaneously from the vehicle to the service technician's computer without requiring the 
customer to get out of the vehicle. The infrared connection may be achieved by attaching a serial 
infrared connector to a serial port on the server and by ensuring that there is an unobstructed path 
for JR transmission between the LED's of the infrared connector and that of the service 
technician's computer. 

As will be apparent, the reliability of an infrared data link is improved with the implementation 
of a robust protocol which detects transmission errors and avoids collisions by operating in a 
half-duplex fashion. Such protocols are known and have, for example, been implemented by 
computer and software manufacturers for incorporation in consumer electronic products such as 
micro-computers, modems and cellular phones (i.e. the IrDA stack). Suitable protocols are 
described in Infrared Data Association, "Serial Inared Link Access Protocol (IrLAP)", Version 
1.1, June 1996 and Infrared Data Association, "Link Management Protocol", Version 1.1, 
January 1996, the contents of both of which are incorporated herein by reference. 
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Through compliance with these infrared protocols, the server achieves a goal of rendering client 
test equipment independent of the OBD protocols. Accordingly, any micro-computing equipment 
which is infrared-aware, such as a desk-top, notebook or palm-top (Personal Digital Assistant or 
PDA) can effectively become a remote client. 

In an alternative embodiment, the infrared data link may be replaced or enhanced by 
incorporating mobile wireless data links, coupled with the UDP/IP infrastructure for peer-to-peer 
client/server exchanges over a wide area network. This adaptation of the system extends the 
range of the services offered by the server beyond its capabilities with only the infrared 
connector and data link. The principles described in the previous sections remain the same, with 
the exception that access to OBD information no longer requires that the vehicle be moved 
within infrared detection range (typically 2-5 meters) of the test equipment. The vehicle can be in 
any location which is reachable on the Internet, via a mobile data link. 

The system of the present invention may further comprise a means to transmit generated 
operational information to a remote client, in the absence of a request from the client, when the 
generated operational information satisfies predetermined criteria. Such transmissions of the 
generated operational information implies that server 625 effectively becomes a client with 
respect to a remote site which is capable of logging the transmission. This functionality can be 
achieved by utilizing the peer-to-peer communication architecture described above and is useful 
in, for example, alarm/emergency situations. 

If, for example, while monitoring the exhaust emissions of a vehicle on the road, the level of 
carbon monoxide in the exhaust gases exceeds a predetermined level, the diagnostic means can 
communicate this information directly to server 625 via communication line 675. Server 625 can 
then transmit an alarm report to a remote site advising of the problem. This report can be 
transmitted in real-time, allowing the problem to be dealt with immediately, rather than having to 
wait until the vehicle undergoes routine servicing and diagnosis, days or even months after the 
problem has first come to light. 
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It is envisioned that the threshold values for alarms, as well as the frequency and duration of the 
alarm message, can be configured either directly at the server during installation or servicing, or 
by using remote commands from the client. 

The system described herein may also incorporate Internet access technology for the drivers or 
passengers. The existing method of Internet access for individual personal computers (PC) is 
well-known. The PC establishes a serial link with a computer which has a permanent Internet 
(IP) address. The latter computer, for the purposes of this description, can be called a gateway. 
The serial link is physically either a direct cable connection or via a telephone circuit, using 
modems at both ends of the link. The PC does not have a permanent IP address. It is assigned a 
temporary IP address by the gateway for the duration of the connection. Therefore, if the link is 
maintained via a telephone circuit, then the connection automatically terminates when the circuit 
is dropped and the temporarily assigned IP address ceases to be valid. 

One of the conventional methods of Internet access from a vehicle follows the technique 
described above, using an analog cellular phone and a cellular modem. By connecting the PC to 
the cellular modem, the driver/passenger can obtain a temporary IP address in the same fashion 
as with wired telephony. 

Another method of Internet access from a vehicle is a technology called Cellular Digital Packet 
Data (CDPD), which is a form of packet-switching overlaid on the existing analog cellular 
infrastructure in the United States. CDPD operates with a portion of the bandwidth of the analog 
cellular system and provides a multiple access data link technology within each cellular base 
station's territory of coverage. However, contrary to the method already described, the network 
architecture of CDPD also allows each access device (CDPD modem) to have its own permanent 
IP address. Therefore, no dial-up connection is required to establish the presence of the PC on 
the Internet. It suffices for the PC to be connected to the CDPD modem (which is typically in the 
form of a credit-card style PCMCIA card) for any Internet traffic from another location to reach 
the PC. 
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IP V6 is a new version of the Internet Protocol. One of the design objectives of IP V6 is to 
enable portable computing devices (notebooks, palm-tops, etc.) to have permanent IP addresses 
which can be reached regardless of where the portable device is physically connected to the 
Internet. Therefore, the device could be connected, at different times, to both an office LAN 
(Local Area Network) as well as a residential LAN, without requiring manual intervention by a 
network administrator in either LAN to ensure delivery of Internet traffic. This is achieved by 
ensuring that both LAN's have at least one node (computer) which acts as a "Mobility Agent". 
The Mobility Agent incorporates software which implements IP V6 and related protocols. The 
purpose of the mobility-related functions in this software is to ensure that roaming computing 
devices are automatically "discovered" when they establish a link to the Mobility Agent and that 
the rest of the Internet is informed of the new path which must be used to route traffic to the 
roaming device. Only those routers in the Internet which have been upgraded to support IP V6 
will participate in this function. 

A Mobility Agent can reside in a mobile environment as well as a fixed LAN. This scenario is a 
distinct departure from the existing models of Internet access already described. A mobile 
Mobility Agent, installed in a vehicle in the form of a mobile computer, can effectively "host" 
any IP V6-enable portable computing device, provided that it has a wireless data link to a 
network which is capable of routing packets on the Internet, such as CDPD. The implication is 
that if a vehicle is equipped with a Mobility Agent using, for instance, CDPD, then any portable 
device which a driver or passenger wishes to use in the vehicle to obtain access to the Internet 
does not also need the CDPD modem. It only requires the IP V6 software. 

In order to equip any vehicle with IP V6 support, a hardware platform is required to host all of 
the required protocols and to provide the data links for portable devices trying to connect to the 
Mobility Agent. In order to support the SAE diagnostic test modes in the remote fashion 
described herein, the server contains all of the components which will also allow it to function as 
a mobile Mobility Agent. 

It is envisioned that the Infrared port (and IrDA protocols), which is primarily useful for OBD 
diagnostic test modes while the vehicle is stationary and being examined, can "double" as an in- 
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vehicle wireless point of entry to the internet for portable devices operated by the 
driver/passengers. 
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